code reviewの目的は方針の共有

という説

なぜ不可能なのかというと、理解するモチベがないから

独立したpackageを開発している場合、課題感はpackageごとに異なる

担当しているpackgeを完成させるのがその担当者の責任

他の人からしたら、「現時点」ではあまり関係がない

差し迫っているわけでもないのでモチベが湧かないし、時間もかかる

「code reviewの意義」のようなものを改めて考えたい

当初、code reviewは互いにコードを完全に理解し合う作業、と捉えていた

が、多分違う

理解

そもそも自分のコードですら、昔書いた内容は忘れる

code review時に独立したpackageのことなら、今理解する必要はない

方針が共有されていればい

コードを抽象化した方針

そこを読み解いて理解してacceptする

ドキュメントかPRのメッセージあたりで方針を掴む

実際に自分が修正する必要が出てきた時、自分のpackageと通信が発生した時に初めてちゃんと理解すれば良い

違反の指摘

これは最低限必要なもの

いやちょっと違うかも

コードにおいて違反なんてほぼなくて、実現したい挙動が達成できてるなら、別の視点煮立てば「正しい」と言える

仕様を満たしていない、とかはあるかもだが

こちらもやはり「方針」の共有といってまとめられそう

宣言的に書こうね、immutableにしようね、PBFにしようね、といった「コーディング規約」みたいなやつも、レイヤーの異なる「方針」と言える

Package的な観点から言えば、詳細は寧ろ知らない方がいい、とも言える？

方針を変えるPRと、その方針のもとで新たに実装したPRとある

前者の場合は、元のものの課題を批判しつつ、解決策の提案を明示する

後者は普通に(?)実装する(?)

コードレビューもコードリーディングも似たようなもの

diffの全てに目を通すことが目的ではない

方針が掴めたら別に読まなくてもいい

Aの方が詳しいものに対して、Bにお願いしている時、

Aがレビューした時に、Bにアドバイスすることはできるだろう

Aが詳しいpackageについて、Aが実装した時、

Cはそれをレビューする際に全て理解する必要はないだろう

ただし、属人化しないように努めるのは大事そう

Aがいなくなった時に、他のメンバーが理解できる状態である必要はある

Aがドキュメントを書いておくとかが良いが、それを事前に常にやるのも難しい

モチベがないので

理想的には、全メンバーが、順番に各packageを見るようにタスクを降れば良いが

機能XをAが作り、機能追加はBが見る、バグ修正はCがやる、みたいな

それはそれで本当に効率的なのか？かなり疑問

これは、「フロントエンドエンジニア」とか「フルスタックエンジニア」みたいな分け方にも同じ問題がありそう

全体を知っていることの良さ、属人化して回すことの良さ、また、その悪さを見て、

何を目的として突き進むかの方針が必要

これも業務とかに依る

業務委託系なら、誰でも回せるように準備しておくべき、みたいな

抽象レベルで認識を合わせるのもそれはそれで難しそうではあるが

型だけ書くとか、Figmaとか形式手法とかER図とかそういう概念で会話するとか？

課題によっては自然言語でも十分だろうけど